home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / internet-drafts / draft-ietf-pppext-ipxcp-03.txt < prev    next >
Text File  |  1993-04-19  |  28KB  |  1,099 lines
  1.  
  2.  
  3. Network Working Group                                        W A Simpson
  4. Internet Draft                                                Daydreamer
  5. expires in six months                                         April 1993
  6.  
  7.  
  8.  
  9.      The PPP Internetwork Packet Exchange Control Protocol  (IPXCP)
  10.  
  11.  
  12.  
  13. Status of this Memo
  14.  
  15.    This memo is the product of the Point-to-Point Protocol Working Group
  16.    of the Internet Engineering Task Force (IETF).  Comments on this memo
  17.    should be submitted to the ietf-ppp@ucdavis.edu mailing list.
  18.  
  19.    Distribution of this memo is unlimited.
  20.  
  21.    This document is an Internet Draft.  Internet Drafts are working
  22.    documents of the Internet Engineering Task Force (IETF), its Areas,
  23.    and its Working Groups.  Note that other groups may also distribute
  24.    working documents as Internet Drafts.  Internet Drafts are draft
  25.    documents valid for a maximum of six months.  Internet Drafts may be
  26.    updated, replaced, or obsoleted by other documents at any time.  It
  27.    is not appropriate to use Internet Drafts as reference material or to
  28.    cite them other than as a ``working draft'' or ``work in progress.''
  29.    Please check the 1id-abstracts.txt listing contained in the
  30.    internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
  31.    nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
  32.    current status of any Internet Draft.
  33.  
  34. Abstract
  35.  
  36.    The Point-to-Point Protocol (PPP) [1] provides a standard method of
  37.    encapsulating Network Layer protocol information over point-to-point
  38.    links.  PPP also defines an extensible Link Control Protocol, and
  39.    proposes a family of Network Control Protocols for establishing and
  40.    configuring different network-layer protocols.
  41.  
  42.    The IPX protocol was originally used in Novell's NetWare products
  43.    [3], and is now supported by numerous other vendors.  This document
  44.    defines the Network Control Protocol for establishing and configuring
  45.    the IPX protocol over PPP.
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54. Simpson                  expires in six months                  [Page i]
  55. DRAFT                          PPP IPXCP                      April 1993
  56.  
  57.  
  58. 1.  Introduction
  59.  
  60.    PPP has three main components:
  61.  
  62.       1. A method for encapsulating datagrams over serial links.
  63.  
  64.       2. A Link Control Protocol (LCP) for establishing, configuring,
  65.          and testing the data-link connection.
  66.  
  67.       3. A family of Network Control Protocols (NCPs) for establishing
  68.          and configuring different network-layer protocols.
  69.  
  70.    In order to establish communications over a point-to-point link, each
  71.    end of the PPP link must first send LCP packets to configure and test
  72.    the data link.  After the link has been established and optional
  73.    facilities have been negotiated as needed by the LCP, PPP must send
  74.    NCP packets to choose and configure one or more network-layer
  75.    protocols.  Once each of the chosen network-layer protocols has been
  76.    configured, datagrams from each network-layer protocol can be sent
  77.    over the link.
  78.  
  79.    The link will remain configured for communications until explicit LCP
  80.    or NCP packets close the link down, or until some external event
  81.    occurs (an inactivity timer expires or network administrator
  82.    intervention).
  83.  
  84.    In the case of IPX, the term NCP does not apply to the IPX protocol
  85.    of the same acronym.
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109. Simpson                  expires in six months                  [Page 1]
  110. DRAFT                          PPP IPXCP                      April 1993
  111.  
  112.  
  113. 2.  A PPP Network Control Protocol (NCP) for IPX
  114.  
  115.    The IPX Control Protocol (IPXCP) is responsible for configuring,
  116.    enabling, and disabling the IPX protocol modules on both ends of the
  117.    point-to-point link.  IPXCP uses the same packet exchange machanism
  118.    as the Link Control Protocol (LCP).  IPXCP packets may not be
  119.    exchanged until PPP has reached the Network-Layer Protocol phase.
  120.    IPXCP packets received before this phase is reached should be
  121.    silently discarded.
  122.  
  123.    The IPX Control Protocol is exactly the same as the Link Control
  124.    Protocol [1] with the following exceptions:
  125.  
  126.    Frame Modifications
  127.  
  128.       The packet may utilize any modifications to the basic frame format
  129.       which have been negotiated during the Link Establishment phase.
  130.  
  131.    Data Link Layer Protocol Field
  132.  
  133.       Exactly one IPXCP packet is encapsulated in the Information field
  134.       of a PPP Data Link Layer frame where the Protocol field indicates
  135.       type hex 802B (IPX Control Protocol).
  136.  
  137.    Code field
  138.  
  139.       Only Codes 1 through 7 (Configure-Request, Configure-Ack,
  140.       Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack
  141.       and Code-Reject) are used.  Other Codes should be treated as
  142.       unrecognized and should result in Code-Rejects.
  143.  
  144.    Timeouts
  145.  
  146.       IPXCP packets may not be exchanged until PPP has reached the
  147.       Network-Layer Protocol phase.  An implementation should be
  148.       prepared to wait for Authentication and Link Quality Determination
  149.       to finish before timing out waiting for a Configure-Ack or other
  150.       response.  It is suggested that an implementation give up only
  151.       after user intervention or a configurable amount of time.
  152.  
  153.    Configuration Option Types
  154.  
  155.       IPXCP has a distinct set of Configuration Options, which are
  156.       defined below.
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164. Simpson                  expires in six months                  [Page 2]
  165. DRAFT                          PPP IPXCP                      April 1993
  166.  
  167.  
  168. 2.1.  Sending IPX Datagrams
  169.  
  170.    Before any IPX packets may be communicated, PPP must reach the
  171.    Network-Layer Protocol phase, and the IPX Control Protocol must reach
  172.    the Opened state.
  173.  
  174.    Exactly one IPX packet is encapsulated in the Information field of a
  175.    PPP Data Link Layer frame where the Protocol field indicates type hex
  176.    002B (IPX).
  177.  
  178.    The maximum length of an IPX datagram transmitted over a PPP link is
  179.    the same as the maximum length of the Information field of a PPP data
  180.    link layer frame.  Since there is no standard method for fragmenting
  181.    and reassembling IPX datagrams, PPP links supporting IPX MUST allow
  182.    at least 576 octets in the information field of a data link layer
  183.    frame.
  184.  
  185.  
  186. 2.2.  IPX-WAN protocol
  187.  
  188.    Novell has recently announced a new specification called IPX-WAN [4],
  189.    which is intended to provide mechanisms similar to IPXCP negotiation
  190.    over wide area links.  As viewed by PPP, IPX-WAN is a part of IPX,
  191.    and IPX-WAN packets are indistinguishable from other IPX packets.
  192.  
  193.    As time has progressed, Novell has improved IPX-WAN by adding the
  194.    functional equivalent of each feature proposed in earlier drafts of
  195.    this document.
  196.  
  197.  
  198. 2.3.  Historical Context
  199.  
  200.    Previous drafts of this specification have introduced a NCP with
  201.    several configuration options, and another NCP having no
  202.    configuration options, with some NCP functions moved to the IPX-WAN
  203.    protocol.  This specification proposes the union of the previous
  204.    proposals, with instructions for interoperating between the two
  205.    environments.
  206.  
  207.    Currently, Novell has implemented IPXCP without any Configuration
  208.    Options, and requires successful IPX-WAN negotiation, even when all
  209.    required parameters have been hand configured.  This makes it
  210.    impossible for the Novell products to interoperate with other
  211.    implementations, which do not already include support for IPX-WAN.
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219. Simpson                  expires in six months                  [Page 3]
  220. DRAFT                          PPP IPXCP                      April 1993
  221.  
  222.  
  223. 2.4.  Required Configuration Parameters
  224.  
  225.    To resolve the possible conflict between the two configuration
  226.    methods, this specification defines the concept of "Required
  227.    Parameters".  Where applicable, each Configuration Option indicates
  228.    the environment where the parameter which is negotiated MAY be
  229.    required by the implementation for proper operation.
  230.  
  231.    This determination is highly implementation dependent.  For example,
  232.    a particular implementation might require that all links have
  233.    addresses, while another implementation might not need such
  234.    addresses.  The configuration negotiation is intended to discover
  235.    that this pair of implementations will never converge.
  236.  
  237.  
  238. 2.5.  Co-existance with IPX-WAN
  239.  
  240.    If unable to negotiate some "Required Parameter", all non-IPX-WAN-
  241.    capable implementations MUST NOT reach Opened state.  Conversely, an
  242.    IPX-WAN-capable implementation SHOULD reach Opened state, even when
  243.    no Configuration Options are successfully negotiated.
  244.  
  245.    IPX-WAN uses a "Timer Request" packet to set up the link.  These MUST
  246.    NOT be sent until IPXCP has Opened the link.
  247.  
  248.    An implementation which provides both IPX-WAN and IPXCP Configuration
  249.    Options capability SHOULD only send a Timer Request packet when a
  250.    Timer Request packet is received, or upon failure to successfully
  251.    negotiate a "Required Parameter".
  252.  
  253.    If unable to complete IPX-WAN setup when a "Required Parameter" is
  254.    unknown, by default IPXCP SHOULD terminate the link.  However, some
  255.    implementations might be capable of operating without all indicated
  256.    "Required Parameters", in which case the termination MUST be
  257.    configurable.
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274. Simpson                  expires in six months                  [Page 4]
  275. DRAFT                          PPP IPXCP                      April 1993
  276.  
  277.  
  278. 3.  IPXCP Configuration Options
  279.  
  280. IPXCP Configuration Options allow negotiation of desirable IPX
  281. parameters.  IPXCP uses the same Configuration Option format defined for
  282. LCP [1], with a separate set of Options.
  283.  
  284. The most up-to-date values of the IPXCP Option Type field are specified
  285. in the most recent "Assigned Numbers" RFC [2].  Current values are
  286. assigned as follows:
  287.  
  288.  
  289.    1       IPX-Network-Number
  290.    2       IPX-Node-Number
  291.    3       IPX-Compression-Protocol
  292.    4       IPX-Routing-Protocol
  293.    5       IPX-Router-Name
  294.    6       IPX-Configuration-Complete
  295.  
  296.  
  297.  
  298.  
  299.  
  300.  
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329. Simpson                  expires in six months                  [Page 5]
  330. DRAFT                          PPP IPXCP                      April 1993
  331.  
  332.  
  333. 3.1.  IPX-Network-Number
  334.  
  335.    Description
  336.  
  337.       This Configuration Option provides a way to negotiate the IPX
  338.       network number to be used on the local end of the link.  It allows
  339.       the sender of the Configure-Request to state which network number
  340.       is desired, or to request that the peer provide the information.
  341.       The peer can provide this information by NAKing the option, and
  342.       returning a valid IPX-Network-Number.
  343.  
  344.       If negotiation about the remote network number is required, and
  345.       the peer did not provide the option in its Configure-Request, the
  346.       option SHOULD be appended to a Configure-Nak.  The value of the
  347.       IPX-Network-Number given must be acceptable as the remote IPX-
  348.       Network-Number, or indicate with a zero value that the peer
  349.       provide the information.
  350.  
  351.       By default, no IPX-Network-Number is assigned to either end.  A
  352.       network specified as zero in a Configure-Request shall be
  353.       interpreted as requesting the remote end to specify a value via a
  354.       Configure-Nak.  A network specified as zero in a Configure-Ack
  355.       shall be interpreted as agreement that no value exists.
  356.  
  357.       This is a Required Parameter when the implementation is operating
  358.       as a router, but not as a half-router or end-system.  By default,
  359.       this parameter SHOULD NOT be negotiated when statically
  360.       configured, unless requested by the peer.  Any IPX-WAN packets
  361.       received MUST supercede information negotiated in this option.
  362.  
  363.    A summary of the IPX-Network-Number Configuration Option format is
  364.    shown below.  The fields are transmitted from left to right.
  365.  
  366.     0                   1                   2                   3
  367.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  368.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  369.    |     Type      |    Length     |       IPX-Network-Number
  370.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  371.    |  IPX-Network-Number (cont.)   |
  372.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  373.  
  374.  
  375.    Type
  376.  
  377.       1
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384. Simpson                  expires in six months                  [Page 6]
  385. DRAFT                          PPP IPXCP                      April 1993
  386.  
  387.  
  388.    Length
  389.  
  390.       6
  391.  
  392.    IPX-Network-Number
  393.  
  394.       The four octet IPX-Network-Number is the desired local IPX network
  395.       number of the sender of the Configure-Request.  This number may be
  396.       zero, which is interpreted as being a local network of unknown
  397.       number that requires no routing.
  398.  
  399.       Both ends of the link MUST have the same network number.  In the
  400.       event of conflict, the end having the highest network number wins.
  401.  
  402.  
  403.  
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412.  
  413.  
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439. Simpson                  expires in six months                  [Page 7]
  440. DRAFT                          PPP IPXCP                      April 1993
  441.  
  442.  
  443. 3.2.  IPX-Node-Number
  444.  
  445.    Description
  446.  
  447.       This Configuration Option provides a way to negotiate the IPX node
  448.       number to be used on the local end of the link.  It allows the
  449.       sender of the Configure-Request to state which node number is
  450.       desired, or to request that the peer provide the information.  The
  451.       peer can provide this information by NAKing the option, and
  452.       returning a valid IPX-Node-Number.
  453.  
  454.       If negotiation about the remote node number is required, and the
  455.       peer did not provide the option in its Configure-Request, the
  456.       option SHOULD be appended to a Configure-Nak.  The value of the
  457.       IPX-Node-Number given must be acceptable as the remote IPX-Node-
  458.       Number, or indicate with a zero value that the peer provide the
  459.       information.
  460.  
  461.       By default, no IPX-Node-Number is assigned to either end.  A node
  462.       number specified as zero in a Configure-Request shall be
  463.       interpreted as requesting the remote end to specify a value via a
  464.       Configure-Nak.  A node number specified as zero in a Configure-Ack
  465.       shall be interpreted as agreement that no value exists.
  466.  
  467.       This is a Required Parameter when the implementation is
  468.       originating traffic as an end-system, but not when operating as a
  469.       router or half-router.  By default, this parameter SHOULD NOT be
  470.       negotiated when statically configured, unless requested by the
  471.       peer.  Any IPX-WAN packets received MUST supercede information
  472.       negotiated in this option.
  473.  
  474.    A summary of the IPX-Node-Number Configuration Option format is shown
  475.    below.  The fields are transmitted from left to right.
  476.  
  477.     0                   1                   2                   3
  478.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  479.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  480.    |     Type      |    Length     |       IPX-Node-Number
  481.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  482.    |                     IPX-Node-Number (cont.)                   |
  483.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  484.  
  485.  
  486.    Type
  487.  
  488.       2
  489.  
  490.  
  491.  
  492.  
  493.  
  494. Simpson                  expires in six months                  [Page 8]
  495. DRAFT                          PPP IPXCP                      April 1993
  496.  
  497.  
  498.    Length
  499.  
  500.       8
  501.  
  502.    IPX-Node-Number
  503.  
  504.       The six octet IPX-Node-Number is the desired local IPX node number
  505.       of the sender of the Configure-Request.  The node number MUST be
  506.       unique within the same network number.
  507.  
  508.  
  509.  
  510.  
  511.  
  512.  
  513.  
  514.  
  515.  
  516.  
  517.  
  518.  
  519.  
  520.  
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531.  
  532.  
  533.  
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549. Simpson                  expires in six months                  [Page 9]
  550. DRAFT                          PPP IPXCP                      April 1993
  551.  
  552.  
  553. 3.3.  IPX-Compression-Protocol
  554.  
  555.    Description
  556.  
  557.       This Configuration Option provides a way to negotiate the use of a
  558.       specific compression protocol.  By default, compression is not
  559.       enabled.
  560.  
  561.       The sender of this Configuration Option indicates that it can
  562.       receive packets with the specified compression technique.  A
  563.       Configure-Ack MAY obligate the peer to send such packets,
  564.       depending on the protocol negotiated.
  565.  
  566.       Information negotiated in this option MUST supercede any IPX-WAN
  567.       packets received, since IPX-WAN packets could be affected by the
  568.       compression technique.
  569.  
  570.    A summary of the IPX-Compression-Protocol Configuration Option format
  571.    is shown below.  The fields are transmitted from left to right.
  572.  
  573.     0                   1                   2                   3
  574.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  575.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  576.    |     Type      |    Length     |   IPX-Compression-Protocol    |
  577.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  578.    |     Data ...
  579.    +-+-+-+-+
  580.  
  581.  
  582.    Type
  583.  
  584.       3
  585.  
  586.    Length
  587.  
  588.       >= 4
  589.  
  590.    IPX-Compression-Protocol
  591.  
  592.       The IPX-Compression-Protocol field is two octets and indicates the
  593.       compression protocol desired.  Odd values for this field are
  594.       always the same as the PPP Data Link Layer Protocol field values
  595.       for that same compression protocol.  Even values are used when the
  596.       compression protocol is interleaved with IPX packets.
  597.  
  598.       The most up-to-date values of the IPX-Compression-Protocol field
  599.       are specified in the most recent "Assigned Numbers" RFC [2].
  600.       Current values are assigned as follows:
  601.  
  602.  
  603.  
  604. Simpson                  expires in six months                 [Page 10]
  605. DRAFT                          PPP IPXCP                      April 1993
  606.  
  607.  
  608.  
  609.          Value (in hex)  Protocol
  610.  
  611.          0002            Telebit Compressed IPX
  612.          0235            Shiva Compressed NCP/IPX
  613.  
  614.  
  615.    Data
  616.  
  617.       The Data field is zero or more octets and contains additional data
  618.       as determined by the particular compression protocol.
  619.  
  620.  
  621.  
  622.  
  623.  
  624.  
  625.  
  626.  
  627.  
  628.  
  629.  
  630.  
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637.  
  638.  
  639.  
  640.  
  641.  
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659. Simpson                  expires in six months                 [Page 11]
  660. DRAFT                          PPP IPXCP                      April 1993
  661.  
  662.  
  663. 3.4.  IPX-Routing-Protocol
  664.  
  665.    Description
  666.  
  667.       This Configuration Option provides a way to negotiate the use of a
  668.       specific routing protocol (or no routing protocol, if desired).
  669.       The sender of this option is specifying that it wishes to receive
  670.       information of the specified routing protocol.  Multiple protocols
  671.       MAY be requested by sending multiple IPX-Routing-Protocol
  672.       Configuration Options.
  673.  
  674.       By default, Novell's combination of Routing Information Protocol
  675.       (RIP) and Server Advertising Protocol (SAP) is expected.
  676.  
  677.       This is a Required Parameter when the implementation is operating
  678.       as an end-system, and in that case SHOULD be negotiated even when
  679.       statically configured.  Any IPX-WAN packets received MAY add to
  680.       information negotiated in this option.
  681.  
  682.    A summary of the Routing-Protocol Configuration Option format is
  683.    shown below.  The fields are transmitted from left to right.
  684.  
  685.     0                   1                   2                   3
  686.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  687.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  688.    |     Type      |    Length     |       Routing-Protocol        |
  689.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  690.    |     Data ...
  691.    +-+-+-+-+
  692.  
  693.  
  694.    Type
  695.  
  696.       4
  697.  
  698.    Length
  699.  
  700.       >= 4
  701.  
  702.    Routing-Protocol
  703.  
  704.       The Routing-Protocol field is two octets and indicates the type of
  705.       Routing-Protocol desired.  This two octet quantity is sent most
  706.       significant octet first.
  707.  
  708.       Initial values are assigned as follows:
  709.  
  710.  
  711.  
  712.  
  713.  
  714. Simpson                  expires in six months                 [Page 12]
  715. DRAFT                          PPP IPXCP                      April 1993
  716.  
  717.  
  718.  
  719.       Value           Protocol
  720.  
  721.         0             No routing protocol required
  722.         1             RESERVED
  723.         2             Novell RIP/SAP required
  724.         3             Novell NLSP required
  725.  
  726.  
  727.    Data
  728.  
  729.       The Data field is zero or more octets and contains additional data
  730.       as determined by the routing protocol indicated in the Routing-
  731.       Protocol field.
  732.  
  733.  
  734.  
  735.  
  736.  
  737.  
  738.  
  739.  
  740.  
  741.  
  742.  
  743.  
  744.  
  745.  
  746.  
  747.  
  748.  
  749.  
  750.  
  751.  
  752.  
  753.  
  754.  
  755.  
  756.  
  757.  
  758.  
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766.  
  767.  
  768.  
  769. Simpson                  expires in six months                 [Page 13]
  770. DRAFT                          PPP IPXCP                      April 1993
  771.  
  772.  
  773. 3.5.  IPX-Router-Name
  774.  
  775.    Description
  776.  
  777.       This Configuration Option provides a way to convey information
  778.       about the IPX server name.
  779.  
  780.       The nature of this option is advisory only.  It is provided as a
  781.       means of improving the end system's ability to provide a simple
  782.       user interface.  This option MUST NOT be included in a Configure-
  783.       Nak.
  784.  
  785.    A summary of the IPX-Router-Name Option format is shown below.  The
  786.    fields are transmitted from left to right.
  787.  
  788.     0                   1                   2                   3
  789.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  790.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  791.    |     Type      |    Length     |           Name...
  792.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  793.  
  794.  
  795.    Type
  796.  
  797.       5
  798.  
  799.    Length
  800.  
  801.       >= 3
  802.  
  803.    Name
  804.  
  805.       This field contains the name of the IPX entity on this end of the
  806.       link.  The symbolic name should be between 1 and 47 ASCII
  807.       characters in length, containing the characters 'A' through 'Z',
  808.       underscore (_), hyphen (-) and "at" sign (@).  The length of the
  809.       name is bounded by the option length.
  810.  
  811.       On reception, the name SHOULD be padded to 48 characters using the
  812.       NUL character.  Those readers familiar with NetWare 3.x servers
  813.       will realize that this is equivalent to the file server name.
  814.  
  815.  
  816.  
  817.  
  818.  
  819.  
  820.  
  821.  
  822.  
  823.  
  824. Simpson                  expires in six months                 [Page 14]
  825. DRAFT                          PPP IPXCP                      April 1993
  826.  
  827.  
  828. 3.6.  IPX-Configuration-Complete
  829.  
  830.    Description
  831.  
  832.       This Configuration Option provides a way to indicate that all
  833.       implementation-dependent Required Parameters are satisfied.  It is
  834.       provided as a means of detecting when convergence will occur in a
  835.       heterogeneous environment.
  836.  
  837.       This option SHOULD be included in a Configure-Request when the
  838.       combination of statically configured parameters and offered
  839.       Configuration Options will result in successful configuration.
  840.  
  841.       The nature of this option is advisory only.  This option MUST NOT
  842.       be included in a Configure-Nak.
  843.  
  844.          Implementation Note: An implementation which does not support
  845.          IPX-WAN can immediately detect that link setup will not be
  846.          successful when some Required Parameter is missing, if this
  847.          option is not present in the peer's Configure-Request or is
  848.          Rejected.  This avoids timeout delays.
  849.  
  850.          An implementation which supports IPX-WAN may improve link setup
  851.          time by skipping IPX-WAN entirely when this option has been
  852.          Ack'd in both directions.
  853.  
  854.          However, it is perfectly acceptable to complete configuration
  855.          without including this option.  There is no reason why an
  856.          implementation which includes the entire panoply of
  857.          configuration options and IPX-WAN cannot interoperate with an
  858.          implementation which does not have IPX-WAN or any configuration
  859.          options (including this one), as long as the Required
  860.          Parameters are satisfied by default or hand configuration.
  861.  
  862.    A summary of the IPX-Configuration-Complete Option format is shown
  863.    below.  The fields are transmitted from left to right.
  864.  
  865.     0                   1
  866.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  867.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  868.    |     Type      |    Length     |
  869.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  870.  
  871.  
  872.    Type
  873.  
  874.       6
  875.  
  876.  
  877.  
  878.  
  879. Simpson                  expires in six months                 [Page 15]
  880. DRAFT                          PPP IPXCP                      April 1993
  881.  
  882.  
  883.    Length
  884.  
  885.       2
  886.  
  887.  
  888.  
  889.  
  890.  
  891.  
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898.  
  899.  
  900.  
  901.  
  902.  
  903.  
  904.  
  905.  
  906.  
  907.  
  908.  
  909.  
  910.  
  911.  
  912.  
  913.  
  914.  
  915.  
  916.  
  917.  
  918.  
  919.  
  920.  
  921.  
  922.  
  923.  
  924.  
  925.  
  926.  
  927.  
  928.  
  929.  
  930.  
  931.  
  932.  
  933.  
  934. Simpson                  expires in six months                 [Page 16]
  935. DRAFT                          PPP IPXCP                      April 1993
  936.  
  937.  
  938. Security Considerations
  939.  
  940.    Security issues are not discussed in this memo.
  941.  
  942.  
  943. References
  944.  
  945.    [1]   Simpson, W. A., "The Point-to-Point Protocol (PPP)", RFC 1331,
  946.          May 1992.
  947.  
  948.    [2]   Reynolds, J.K., Postel, J.B., "Assigned Numbers", RFC 1340,
  949.          July 1992.
  950.  
  951.    [3]   Novell Inc., "NetWare System Interface Technical Overview",
  952.          Novell  Part Number 883-001143-001
  953.  
  954.    [4]   Allen, M., "Novell IPX Over Various WAN Media", Novell Inc.,
  955.          June 1992.
  956.  
  957.    [5]   Mathu, Saroop, Lewis, Mark, "Compressing IPX Headers Over WAN
  958.          Media (CIPX)", work-in-progress, April 1993.
  959.  
  960.  
  961. Acknowledgments
  962.  
  963.    Some of the text in this document is taken from previous documents
  964.    produced by the Point-to-Point Protocol Working Group of the Internet
  965.    Engineering Task Force (IETF).
  966.  
  967.    This document is derivative of drafts written by the following
  968.    people.  Many thanks for their work, and for taking an initial stab
  969.    at the protocol:
  970.  
  971.               Michael Allen (mallen@novell.com)
  972.               Dave McCool (dave@shiva.com)
  973.               Robert D Vincent (bert@shiva.com)
  974.               Marty Del Vecchio (marty@shiva.com)
  975.  
  976.  
  977.  
  978. Chair's Address
  979.  
  980.    The working group can be contacted via the current chair:
  981.  
  982.       Fred Baker
  983.       Advanced Computer Communications
  984.       315 Bollay Drive
  985.       Santa Barbara, California, 93111
  986.  
  987.  
  988.  
  989. Simpson                  expires in six months                 [Page 17]
  990. DRAFT                          PPP IPXCP                      April 1993
  991.  
  992.  
  993.       EMail: fbaker@acc.com
  994.  
  995.  
  996. Author's Address
  997.  
  998.    Questions about this memo can also be directed to:
  999.  
  1000.       William Allen Simpson
  1001.       Daydreamer
  1002.       Computer Systems Consulting Services
  1003.       P O Box 6205
  1004.       East Lansing, MI  48826-6205
  1005.  
  1006.       EMail: Bill.Simpson@um.cc.umich.edu
  1007.  
  1008.  
  1009.  
  1010.  
  1011.  
  1012.  
  1013.  
  1014.  
  1015.  
  1016.  
  1017.  
  1018.  
  1019.  
  1020.  
  1021.  
  1022.  
  1023.  
  1024.  
  1025.  
  1026.  
  1027.  
  1028.  
  1029.  
  1030.  
  1031.  
  1032.  
  1033.  
  1034.  
  1035.  
  1036.  
  1037.  
  1038.  
  1039.  
  1040.  
  1041.  
  1042.  
  1043.  
  1044. Simpson                  expires in six months                 [Page 18]
  1045. DRAFT                          PPP IPXCP                      April 1993
  1046.  
  1047.  
  1048.                            Table of Contents
  1049.  
  1050.  
  1051.      1.     Introduction ..........................................    1
  1052.  
  1053.      2.     A PPP Network Control Protocol (NCP) for IPX ..........    2
  1054.         2.1       Sending IPX Datagrams ...........................    3
  1055.         2.2       IPX-WAN protocol ................................    3
  1056.         2.3       Historical Context ..............................    3
  1057.         2.4       Required Configuration Parameters ...............    4
  1058.         2.5       Co-existance with IPX-WAN .......................    4
  1059.  
  1060.      3.     IPXCP Configuration Options ...........................    5
  1061.         3.1       IPX-Network-Number ..............................    6
  1062.         3.2       IPX-Node-Number .................................    8
  1063.         3.3       IPX-Compression-Protocol ........................   10
  1064.         3.4       IPX-Routing-Protocol ............................   12
  1065.         3.5       IPX-Router-Name .................................   14
  1066.         3.6       IPX-Configuration-Complete ......................   15
  1067.  
  1068.      SECURITY CONSIDERATIONS ......................................   17
  1069.  
  1070.      REFERENCES ...................................................   17
  1071.  
  1072.      ACKNOWLEDGEMENTS .............................................   17
  1073.  
  1074.      CHAIR'S ADDRESS ..............................................   17
  1075.  
  1076.      AUTHOR'S ADDRESS .............................................   18
  1077.  
  1078.  
  1079.  
  1080.  
  1081.  
  1082.  
  1083.  
  1084.  
  1085.  
  1086.  
  1087.  
  1088.  
  1089.  
  1090.  
  1091.  
  1092.  
  1093.  
  1094.  
  1095.  
  1096.  
  1097.  
  1098.  
  1099.